With the emergence and proliferation of wireless technology, the Internet today has evolved to a stage where numerous data communication end-points are made up of mobile terminals, each roaming through different domains and attaching itself to different points of attachment to the packet-switched data communication network (such as, the Internet) at different points in time.
Such roaming provisioning is fairly matured in a circuit-switched communication network, such as the phone system. In a packet-switched communication network, however, supporting such roaming capabilities is difficult. This is because terminals in a packet-switched communication network are reached using unique addresses, and such addresses usually contain portions (usually the prefix) that must be valid in a spatial topology.
In addition, it is desirable for mobile terminals to continue be reached at the same address after a plurality of change of point of attachment to the packet-switched data communication network. This allows seamless continuation of sessions (such as file transfer) across different points of attachment to the packet-switched data communication network.
To support such roaming capabilities, the industry has developed solutions for mobility support as addressed by Mobile IPv4 (the following Non-patent document 1) in Internet Protocol version 4 (IPv4) (the following Non-patent document 2) and Mobile IPv6 (the following Non-patent document 3) in Internet Protocol version 6 (IPv6) (the following Non-patent document 4). In Mobile IP, each data communication terminal (called a mobile node) has a permanent home domain. When the mobile node is attached to its home network, it is assigned a permanent global address known as a home address.
When the mobile node is away, i.e. attached to some other foreign networks, it is usually assigned a temporary global address known as a care-of address. Such a temporary address is usually assigned by the access router the mobile node is associated to, and is aggregated at the address topology of the access router s that the care-of address is topologically correct in the routing infrastructure of the global network.
The idea of mobility support is such that the mobile node can be reached at the home-address even when it is attached to other foreign networks, so that other nodes in the packet-switched data communication network need only identify the mobile node by the mobile node's home address.
This is done in the Non-patent documents 1 and 3 with an introduction of an entity at the home network known as a home agent. Mobile nodes register their care-of-addresses with the home agents using messages known as Binding Updates.
The home agent is responsible to intercept messages that are addressed to the mobile node's home-address, and forwards the packet to the mobile node's care-of-address using IP-in-IP Tunneling (the following Non-patent documents 5 and 6). IP-in-IP tunneling involves encapsulating an original IP packet in another IP packet. The original packet is sometimes referred to as the inner packet, and the new packet that encapsulates the inner packet is referred to as the outer packet. Such a binding between home-addresses and care-of-addresses, made known at the home agent of the mobile node, allows the mobile node to be reached no matter where the mobile node is.
It is possible to extend the concept of host mobility support as stipulated in the Non-patent documents 1 and 3 to network mobility support (NEMO) (the following patent document 1 and Non-patent document 7). This is the case where the mobile node is itself a mobile router, and a plurality of nodes move together with the mobile router, forming a mobile network. After the mobile router sends a Binding Update message to its home agent, packets sent to the mobile network are intercepted by the home agent and tunneled to the mobile router.
The mobile router then decapsulates the tunnel packet, and forwards the inner packet to the destination. Similarly, packet sent from a node in the mobile network is tunneled to the home agent by the mobile router to be forwarded to the correct destination. The mobile router itself may act as an access router, allowing other mobile node (mobile host or mobile router) to associate with the mobile router and gain access to the global communication network through it.
In the Non-patent document 7, Binding Update messages sent by the mobile Router can be constructed in two distinct modes: an implicit mode where no information of the mobile network prefix is specified and an explicit mode where the mobile router will place its mobile network prefix within the Binding Update message.
Implicit mode is used when prefix information is manually configured at the home agent, and the home agent can construct the routing table to forward packets sent to the mobile network without having the mobile router to explicitly state its mobile network prefix or prefixes.
Explicit mode allows the mobile router to explicitly state the mobile network prefix or prefixes it is managing. This frees the home agent from needing to know the prefix information in advance.
Home agents are required to send responses indicating the status of a Binding Update back to the mobile router in the form of a Binding Acknowledgement message. When the binding fails, different status values in Binding Acknowledgement will give an indication of the reason of failure. It can either be an error in setting up the forwarding mechanism, or that the mobile router is unauthorized to set up the binding for the specified prefix or prefixes.
When the home agent does not have prior knowledge of prefixes belonging to a mobile router, it can send back a negative acknowledgement to an implicit mode Binding Update with the reason of forwarding set-up failure. When an explicit mode Binding Update specifies a wrong or unauthorized prefix or prefixes, the home agent can send back a negative Binding Acknowledgement with the reason of unauthorized prefix.    [Non-patent document 1] Perkins, C. E. et. al., “IP Mobility Support”, IETF RCF 3344, August 2002.    [Non-patent document 2] DARPA, “Internet Protocol”, IETF RFC 791, September 1981.    [Non-patent document 3] Johnson, D. B., Perkins, C. E., and Arkko, J., “Mobility Support in IPv6”, IETF Internet Draft: draft-ietf-mobileip-ipv6-24.txt, Work In Progress, June 2003.    [Non-patent document 4] Deering, S., and Hinden, R., “Internet Protocol Version 6 (IPv6) Specification”, IETF RFC 2460, December 1998.    [Non-patent document 5] Simpson, W., “IP in IP Tunneling”, IETF RFC 1853, October 1995.    [Non-patent document 6] Conta, A., and Deering, S., “Generic Packet Tunneling in IPv6”, IETF RFC 2473, December 1998.    [Non-patent document 7] Devarapalli, V., et. al., “NEMO Basic Support Protocol”, IETF Internet Draft: draft-ietf-nemo-basic-01.txt, September 2003.    [Patent document 1] Leung, K. K., “Mobile IP mobile router”, U.S. Pat. No. 6,636,498, October 2003.
In both the Patent document 1 and Non-patent document 7, the mobile router can optionally run a dynamic routing protocol (such as Inter Gateway Protocol:IGP, Realm Specific Internet Protocol:RIP, or Open Shortest Path First:OSPF) over the bi-directional tunnel it established with its home agent, just like when the mobile router is directly attached to its home agent. When the mobile router does so, routing information about the mobile network prefix or prefixes will be disseminated using the routing protocol. However, it was not specified which mode the mobile router should use when sending Binding Update, whether implicit or explicit mode.
Should the mobile router choose to use implicit mode, the response of the home agent is again unclear. Since a dynamic routing protocol is used after the bi-directional tunnel is established, the home agent cannot know the mobile network prefix at the time the implicit mode Binding Update is received. Obviously, the home agent cannot send a negative Binding Acknowledgement, contrary to what is specified in the Non-patent document 7, since it is expecting the prefixes information to come after the bi-directional tunnel is established.
In addition, it cannot know if the mobile router will indeed run a dynamic routing protocol if the home agent responds with a positive Binding Acknowledgement. If the mobile router is not running a dynamic routing protocol, then the home agent should revert back to the expected behavior of sending a negative Binding Acknowledgement with a reason of forwarding set-up failure. But, it has already sent a positive Binding Acknowledgement when in anticipation of a dynamic routing protocol to be run.
On the other hand, if the mobile router chooses to use explicit mode, it is unclear how the home agent should respond if the prefix information conveyed in the Binding Update is not reflected in the dynamic routing message later sent by the mobile router, or even when they are inconsistent.
Thus, the error checking and graceful fail-over mechanism at home agents for running dynamic routing protocol over the bi-directional tunnel are almost non-existent in either mode.